MERGE and lookup are 2 different things. Comparing them is apples and oranges. In this scenario, you'd use the MERGE statement to determine whether the row should be updated or inserted, which negates the need for the lookup.
If you take the lookup approach, remeber that the OLE DB Destination only does inserts. If you don't use the MERGE, you must use an OLE DB Destination to do the inserts, and either a) an OLE DB Command to perform the update, which is slow, since
it sends row by row UPDATE statements to the database, or b) write the "update" data to a working table in the data flow, and use an Execute SQL after the data flow to perform a set-based UPDATE.
Using MERGE gives you a cleaner data flow, since you only have one destinaton (the working table or MERGE capable destination component).
Is it faster? My experience is that MERGE is faster than the OLE DB Command, unless you have a very small number of updates. It's also usually faster than a Lookup in No Cache mode, since that also becomes row-by-row processing against the database.
However, as always, performance is very dependent on the database, so your mileage may vary.
I do use the Lookup approach regularly as well - MERGE isn't an option on onlder versions of SQL Server. Different patterns apply in different situations.